Electronic data resources are often stored in archive data structures or files Archives may be expanded to retrieve the original contents. Archives are often compressed to save memory space. Compressed archives must be both decompressed and expanded to retrieve the original contents. Archives are often nested so that lower-level archives are contained in upper-level archives. A common approach to access archives is to search through layers of nested archives, expanding and decompressing each archive layer if necessary. As a result, archives are often decompressed, expanded and searched repeatedly in use. This repetitive decompression, expansion and searching is time-consuming and may hinder the speedy execution of computer programs making use of archives.
One common type of archive file is a Java Archive file (JAR). Java provides a standard computer programming language and runtime environment. In this environment applications are composed of cooperating Java classes. Java classes are typically organized into packages and stored in JAR files. A typical Java program uses classes from multiple packages stored in multiple JARs. When the program is executed, the classes that the program requires must be extracted from the JARs that contain them and loaded into memory. Java archives provide a compressed archive format which requires decompressing on access. Repeated access to the same JAR requires repeated decompressing. When an application requires many different JARs the task can be very expensive in terms of resource usage.
The access of archived Java classes becomes more complex with the introduction of nested archives in Java 2 Enterprise Edition (J2EE) applications. J2EE applications comprise multiple modules of different types. Each module consists of a resource used by the application, such as Java byte code class files, image files (e.g. gif), property files, HTML or XML files. Each module is packaged as a Java archive file. A variety of types of Java archives exist, such as WAR (web application), EjbJar (ejb code), and others. Certain module types in J2EE allow for the nesting of other module archives within their own structure. The top level J2EE application archive (EAR) is an example. It maintains a nested archive for each of the modules that it contains. In the same way WARs may contain multiple utility archives.
In the example nested structure schematically shown in FIG. 1, in order to locate a file named picture.gif in fooWebResources.jar, the archive fooApp.ear needs to be decompressed to access fooWeb.war which must be decompressed to access fooWebResource.jar which can then be searched for the picture.gif file.
Another problem of accessing nested archives is that some systems do not support searching archives at an arbitrary nesting level. For example, a file associated with a Java application can be located from the archives using a uniform resource locator (URL). A URL for picture.gif could look as follows:
“jar:/fooApp.ear!/fooWeb.war!/fooWebResources.jar!/picture.gif”
However, using the existing jar protocol handler in JDK1.3 accessing the above URL will result in an exception of the form:
“java.io.FileNotFoundException: JAR entry
fooWeb.war!/fooWebResources.jar!/picture.gif not found in fooApp.ear”
The exception occurs because although the JDK1.3 protocol handler supports accessing entries within a jar using the “!/” notation, it cannot locate entries within jars at an arbitrary nesting level.
There are many solutions to the restriction on the current Java JAR protocol handler. One solution is to expand all archives containing nested archives to a file system and mapping JAR entries to file system locations. The existing JAR protocol handler can then be used to access entries within JARs. An alternative solution is to expand archives to the local file system, eliminating use of the JAR protocol handler. These solutions all require a preliminary procedure that expands required archives before an application is executed and this preliminary expansion is undesirable and can be expensive in terms of memory usage.